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Abstract 

The lAU Commission 4 Working Group on Standardizing Access to Ephemerides recom¬ 
mends the use of the Spacecraft and Planet Kernel (SPK) format as a standard format for the 
position ephemerides of planets and other natural solar system bodies, and the use of the Plane¬ 
tary Constants Kernel (PCK) format for the orientation of these bodies. It further recommends 
that other supporting data be stored in a text PCK. These formats were developed for use by 
the SPICE Toolkit by the Navigation and Ancillary Information Eacility of NASA’s Jet Propul¬ 
sion Eaboratory (JPE). The CAECEPH library developed by the Institut de mecanique celeste 
de calcul des ephemerides (IMCCE) is also able to make use of these files. High accuracy 
ephemerides available in files conforming to the SPK and PCK formats include: the Develop¬ 
ment Ephemerides (DE) from JPE, Integrateur Numerique Planetaire de I’Observatoire de Paris 
(INPOP) from IMCCE, and the Ephemerides Planets and the Moon (EPM), developed by the 
Institute for Applied Astronomy (I A A). The bulk of this report is a description of the portion 
of PCK and SPK formats required for these ephemerides. New SPK and PCK data types, both 
called Type 20: Chebyshev (Velocity Only), have been added. Other changes to the specification 
are (i) a new object identification number for coordinate time ephemerides and (ii) a set of three 
new data types that use the TCB rather than the TDB time scale for the ephemerides, but are 
otherwise identical to their TDB versions. 
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Recommendation 


To provide a uniform format for the position ephemerides of planets and other natural solar system 
bodies the International Astronomical Union (lAU) Commission 4: Ephemerides Working Group on 
Standardizing Access to Ephemerides recommends: 

1. The use of the Spacecraft and Planet Kernel (SPK) format ( [Bachman] |2014a] ) for the positions 
of solar system bodies. 

2. Supporting data on the ephemerides and simple body orientation ephemerides be stored in text 
Planetary Constants Kernel (PCK) format ( [Wright & Acton] 20131. 

3. The use of the binary PCK format for the orientation of a body when it is too complex to be 


represented using text PCK (Wright & Acton 20131. 
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1 Introduction 


These file formats were developed by the Navigation and Ancillary Information Facility (NAIF) of 
NASA’s Jet Propulsion Faboratory (JPF) as a portion of the SPICE space geometry information sys¬ 
tem. The SPICE documentation refers to PCK and SPK data files as kernels; the same terminology 
will be followed here. 

Most users will want to use either the SPICE Toolkit or CALCEPH, developed hy the In- 
stitut de mecanique celeste de calcul des ephemerides (IMCCE), to access ephemerides stored 
in these formats. 

SPICE is an information system designed to assist in planning and interpreting scientific observa¬ 
tions from space-based instruments. SPICE is also widely used in engineering tasks associated with 
planetary missions. The SPICE system includes a large suite of software that may be incorporated 
into application programs to read SPICE kernels and, using those data, compute derived observation 
geometry, such as altitude, latitude/longitude, and lighting angles. SPICE data and software may be 
used within many different computing environments. The software is available in FORTRAN 77, C, 


IDE and MATEAB from the NAIF web site (NAIF 2015aI. 


In addition to SPICE, CALCEPH, starting with version 2.0, has the ability to read text PCKs, bi¬ 
nary PCKs, and SPKs. CALCEPH was developed primarily to read IMCCE’s Integrateur Numerique 
Planetaire de I’Observatoire de Paris (INPOP) planetary ephemerides. It is a library with interfaces 
to allow it to be linked to programs written in C, FORTRAN 77, and Fortran 90/95/2003. It is avail¬ 


able at the INPOP web site (CALCEPH 20141 and the lAU Commission 4: Ephemerides web site 


(lAU Commission 4, 20151. 


At least three high-accuracy ephemerides, the JPL’s Development Ephemerides (DE), the IM¬ 
CCE’s INPOP, and the Institute of Applied Astronomy’s Ephemerides of Planets and the Moon 
(EPM) ( |EPM[ [2OT3| ) have versions available in the SPK/PCK formats. 

The SPICE Toolkit contains procedures for both writing and reading SPK and PCK files. But 
some users, such as ephemeris developers, may want to access the ephemeris files directly or con¬ 
struct ephemeris files in these formats using their own software. Detailed specification of those por¬ 
tions of the PCK and SPK formats needed for the ephemerides of solar system bodies are required 
to meet this objective. This specification forms the bulk of this report. 

The SPK format is designed to contain ephemerides of multiple bodies. These ephemerides may 
be stored using multiple data type^ Only a few of these types are used for the storage of the position 
ephemerides of natural solar system bodies. The SPK format is similar to the binary PCK format 
( [Bachman] 2014a). The binary PCK format may, among other things, be used to store ephemerides 
of the orientation of bodies (such as a lunar orientation ephemeris), which are too complex to be 
stored using the text PCK format. The specification for the storage of complex body orientation 


ephemerides is included in ^6.2 


The SPK and binary PCK formats are based in turn on the Double Precision Array File (DAE) 
architecture ( Wrightj 2013) to store the double precision (64-bit real number) arrays of ephemeris 
data. That part of the specification of the DAE architecture required to write SPKs and binary PCKs 
is given in ^ 

The information required to specify a binary PCK or SPK fully for a natural solar system body 
is spread throughout the SPICE documentation, available both within the SPICE Toolkit and on the 


NAIF web site NAIF (2015a). The main repositories of the specification of the SPK and binary PCK 
formats are the DAP Required Reading, the SPK Required Reading, the PCK Required Reading, and 


'a data type, in this context, is a method of representing an ephemeris, such as Chebyshev polynomials or orbital 
elements. 
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Table 1: Double precision kernel data types of interest. 


Kernel Type 

Description 

Section 

Number 


Discussed 


SPK 

2 

Chebyshev 

SPK 

3 

Chebyshev 

SPK 

20 

Chebyshev 

SPK 

102 

Chebyshev 

SPK 

103 

Chebyshev 

SPK 

120 

Chebyshev 

PCK 

2 

Chebyshev 

PCK 

102 

Chebyshev 

PCK 

20 

Chebyshev 

PCK 

120 

Chebyshev 


(Position Only) 

(Position and Velocity) 
(Velocity Only) 

(TCB: Position Only) 

(TCB: Position and Velocity) 
(TCB: Velocity Only) 
(Angles) 

(TCB: Angles) 

(Angle Rates) 

(TCB: Angle Rates) 


( 5.3.2 

( 533 

( 533 

( 533 

( 533 

( 533 

( 633 

( 633 

(633 

(633 


the SPICE source code files for the individual SPK and binary PCK data types. Additional data on 
SPKs and PCKs and how they are used and access ed with the SPI CE Toolkit are available in a set of 

( |2015b| p' 


tutorial slides, also available at the NAIE web site 


NAIE 


The purpose of the bulk of this 


report is to bring together in one place that portion of the format specification required for storing an 
ephemeris for a natural solar system body. 

Supporting data cover a wide variety of parameters and other information. Among other things, 
these data may include the orientation of the body as a function of time|^ the parameters used in 
constructing the ephemerides, the values of the parameters, whether they were fixed or solved for as 
a part of the solution, the units used, and the initial conditions. To accommodate this wide variety 
of data and values, the working group recommends storing these supporting data in a text PCK. The 


specification of text PCK is described in (6.1 


To accommodate the requirements of the wider community, NAIE has agreed to make a number 
of additions to the set of SPK kernel types and to make adjustments to the SPICE Toolkit and its 
documentation. These changes are outlined in (|^ Next, (|^ describes the use of coordinate time 
ephemerides in SPK kernels, (Q describes that portion of the DAP architecture required to under¬ 
stand SPKs and binary PCKs, (|^ describes that part of the SPK format required to store orientation 
ephemerides and to understand the organization of SPKs, (|^discusses PCKs, §6.1 [ describes the text 
PCK format for storing supporting data, and §6.2| describes the binary PCK format for storing binary 
Chebyshev polynomials for complex orientation ephemerides such as the Earth and the Moon. 

The six SPK data types, listed in Table for ephemerides of natural solar system bodies are 
described in the sections given in that table. Types 2, 3, and 20 differ from types 102, 103, and 120 
only in the fact that the independent variable in the former three is the TDB time scale while it is the 
TCB time scale for the latter three. The formats of the four binary PCK types, tabulated in Table 
are used to store body orientation ephemerides. The difference between the SPK types and their 
binary PCK counterparts is in how SPICE interprets the results of their evaluation. 


^The tutorials of interest for this paper are: 19: SPK (19_spk.pdf), 20: PCK (20_pck.pdf), 25: Lunar-Earth PCK- 
FK (25Junar-earth_pck-fk.pdf), and 41: Making an SPK (41_making_an_spk.pdf). 

^The orientation of a few bodies, notably the Earth and the Moon, is too complex to be reasonably stored in text 


PCK format. For these exceptions there is the binary PCK format discussed in (6.2 
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2 Changes Made to the binary SPK and PCK Formats 

To accommodate the requirements of the wider community NAIF has agreed to make additions to 
the SPK and PCK types and adjustments to the SPICE Toolkit and its documentation. These changes 


are: 


1. New SPK and PCK data types have been added. The SPK data type, Type 20: Chebyshev 


(Velocity Only), is described in §5.3.4[ and the PCK data type. Type 20: Chebyshev (Angle 
Rates), is described in 


).2.4 


2. The data types beginning with 101 have been reserved for ephemerides where the time argu¬ 
ment uses the TCB rather than TDB time scale. Currently, this designation is applied to SPK 
types 102, 103, and 120 and binary PCK types 102 and 120. These data types differ from SPK 
types 2, 3, and 20 and PCK types 2 and 20 only in the detail that the time argument used to 
extract data from types less than 100 is on the TDB time scale while the time argument for 
types greater than 100 is on the TCB time scale. 

3. Data types 901 through 910 have been reserved for the development of new ephemeris types 
by other groups. Future versions of SPICE may recognize some of these types or other types 
developed by NAIF. Any decision to do so, and what identification number is assigned, is 
solely at the discretion of NAIF. 

4. The ephemeris object numbers (^Q 1000000001, 1000000002, and 1000000003 have been 
reserved for Coordinate Time ephemerides. These ephemerides may store TT—TDB in the X- 
coordinate, TCG—TCB in the Y-coordinate, or both depending on the chosen object number 
( PTTI ). 


3 Coordinate Time Ephemerides 


The coordinate time scale for the ephemerides, either Barycentric Dynamical Time, TDB (lAU 


20081, or Barycentric Coordinate Time, TCB (lAU 2001al, may be stored in a coordinate time 


ephemeris as Chebyshev polynomials. These time scales are stored either as TT - TDB or as TCG - 
TCB, where TT is Terrestrial Time ( |IAU[ |2001b| ) and TCG is Coordinate Geocentric Time ( |IAU 


2001 aI. A Type 2 SPK segment uses TDB and a Type 102 SPK segment uses TCB as the inde¬ 
pendent argument (^5.3.2). NAIF has assigned identification numbers ( §5.1.1| ) for coordinate time 
ephemerides: 

• 1000000001 TT—TDB data are stored in the X-coordinate 

• 1000000002 ^ TCG—TCB data are stored in the T-coordinate 

• 1000000003 ^ TT—TDB data are stored in the X-coordinate and TCG—TCB data are stored 
in the T-coordinate. 

Data in the unused dimensions are set to 0 to prevent formatting errors that might occur when sum¬ 
mary programs are used to display information about the contents of the SPK containing the seg¬ 
ment. The second integer code, normally used to indicate the reference frame (^5.1.2), is set to 
1000000000 to indicate the data being stored is a coordinate time ephemeris. 


The time bounds in the segment summary (^4.2.4) are always given on the TDB time scale. 
SPICE does not currently use or recognize the TCB time scale. CAFCEPH does recognize and 
make use of kernels using the TCB time scale. 

Binary PCKs, like SPKs, use NAIF identification numbers. But the Coordinate time ephemerides 
identification numbers are only recognized by SPK kernels. 
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4 The Double Precision Array (DAF) Architecture 


The SPK and binary PCK formats are based on the Double precision Array File (DAF) architecture. 
DAF was developed as a part of SPICE and written in ANSI standard FORTRAN li^ Thus, some 
of the description of the DAF architecture and the SPK and binary PCK formats is derived directly 
from the FORTRAN 77 concepts of “double precision” and “record length”. 

A FORTRAN 77 DOUBLE PRECISION data type is a floating point numerical value with a nu¬ 
merical precision of approximately 15 digits. It may also be designated REAL*8 in most dialects 
of FORTRAN 77. In Fortran 90 it is a real (kind = selected_real_kind(15)), and is the C 
equivalent of a doubl^ 

Many Fortran files use a fixed record length. Storing and retrieving data from these file takes 
place in blocks with a constant, predetermined number of units. The unit size is platform dependent. 
Usually, it is in bytes. The DAF architecture includes a count of the units in the file that are called 
“addresses”. A DAF address is not the same as a memory address, but is a method of locating data 


within a DAF architecture file (see ^4.1.1). The number of records, double precision arrays, and 
number of elements an array can contain are limited by the number of words or bytes that can be 
addressed. Addresses are stored as 32-bit Fortran integers, which have a maximum positive value of 
2,147,483,647. 

The data in DAF architecture files are stored as “arrays” of DOUBLE PRECISION numbers. DAF 
files are intended to be portable. Thus, the DAF architecture requires the array elements to consist of 
only DOUBLE PRECISION numbers. These arrays may not contain equivalencecj^or encoded integer 
or character values. 


4.1 The Descriptive Summary and Segment Identifier 


Each array contained in a DAF possesses a descriptive summary. These descriptive summaries are 
stored in the Summary Records ( §4.2.4 ). The organization of a summary and its data are the same 
for each array in the DAF. The descriptive summary contains double precision and integer compo¬ 
nents. The number of double precision components, ND, and the number of integer components, 
NI, contained in the array summaries determine the array’s format within the DAF architecture. The 
values for ND and NI are fixed when the array file is created. Any two array files that have the same 
values for ND and NI can be thought of as having the same “format’Q The values selected for ND 


"^SPICE variants CSPICE, Icy, and Mice are also available and maintained by NAIE. These variants are designed to 
make SPICE available to programs written respectively in C, IDL, and Matlab. All three variants are derived from the 
original EORTRAN 77 code. 

^Eortran 90 includes a real kind c_long to assure interoperability with C code. Whether or not c_long is identical 
to double precision is not specified. 

^The Eortran EQUIVALENCE statement performs a function similar to a C union. The EORTRAN 77 code 


DOUBLE PRECISION X 
INTEGER 1(2) 
EQUIVALENCE (X, I) 


could appear in C as 

union data {double x; int i[2];} mydata; 

The stored order of the bytes of the equivalenced integers is dependent on the system architecture. The EQUIVALENCE 
statement has been deprecated in Eortran 90. 

^This does not mean that the individual arrays in a file contain the same kinds of data, only that they may be stored 
in the same DAE architecture file. Both the SPK and binary PCK specifications require that all of the arrays contain data 
pertinent to that kernel type. 
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and NI must satisfy 


2 < A/< 250 and ND <125- 


NI+l 


( 1 ) 


where integer division is used, so {NI + l)/2 is truncated. The final two integer components of the 
summary for an array are always the values of its initial and final addresses ( §4.1.1[ ), so NI > 2. How 
many values are needed and what they contain are left to the designer of a specific DAF type. 

The double precision and integer values that describe each array are “equivalenced” into a dou¬ 
ble precision array before they are stored in the file^. The individual (unpacked) values are the 
components of the summary. The first ND elements of the summary contain the double precision 
components. Each of the remaining elements contains a pair of integer components. If NI is odd, 
the final element of the summary contains a single integer component. 

Each array in an array file is further described by NC characters of alphanumeric information 
called an segment identifier. These segment identifiers are stored in the Name Records ( §4.2.5 1. The 
value of NC is 


NC = + 


A /+1 


( 2 ) 


using integer division. Most segment identifiers are short. For SPKs and binary PCKs they are 
40 characters long. It is desirable, however, to make available alphanumeric data such as producer 
names, archive codes, historical data, or anything else not easily encoded as double precision or 
integer numbers. Thus, segment identifiers should not be used to replace comments in the Comment 


Area ((4.2.31. 


4.1.1 Array Addresses 

Every array file is a FORTRAN 77 direct access file, with a constant record length capable of storing 
up to 128 words. Each word consists of 64 bits and may contain one double precision number. The 
first record of a file contains words 1 through 128. The second record contains words 129 through 
256, etc.. The number of each word is its address within the file. 

The location of each array in an array file is defined by the initial address and final address of 
the array. These addresses are always the values of the final two integer components of the array’s 
descriptive summary. This pair of addresses defines a contiguous set of words, which may fall within 
a single physical record or span a number of records. The elements of each array in an array file are 
stored in such a set. The initial address is the address of the first array element, and the array’s final 
address is the address of the final array element. 

The arrays in an array file form a doubly-linked list. A new array added to a file is placed at 
the tail of the list. The head and tail of the list can be located immediately. The other arrays can be 
located by moving a pointer through the list in either direction. The initial and final addresses may 
be used to access, retrieve, or update the entire array, or any contiguous set of elements therein. 


4.1.2 SPK and Binary PCK 


For both SPK kernels and binary PCK kernels the descriptive summary consists of the two double 
precision and six integer values. The meaning of the values in the summary for a SPK kernel is 


discussed in (5. T and for a binary PCK kernel the meaning of these values are discussed in (6.2 
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4.2 Structure of an Array File 

A DAF array file is a Fortran direct access file. The record length is computer system dependent 
because different systems assign storage in different ways. For SPKs and PCKs the record length is 
set to contain 128 double precision numbers. 


4.2.1 Organization 


An array file contains five types of physical records: 


1. A single File Record (f 4.2.2). This record contains global information about the file. 


2. A Comment Area (f 4.2.31 containing an arbitrary number of Comment Records. These records 


allow the user to store information about the data within the array file. Typical information 
might include the source of the data, or the names of programs used to process and interpret 
it. 

Summary Records (^4.2.4). These contain array descriptive summaries ( §4.1[ ) and pointers 
to other Summary Records. The number of Summary Records in a particular array file is a 
function of the number of arrays stored in the file. 


4. Name Records (f 4.2.51. These contain a character string identifier for each array. An array file 
contains one Name Record for each Summary Record. The length of a name is determined by 
the number of values stored in the Summary record as described in §4.1 

5. An arbitrary number of Element Records ( §4.2.6 ). These contain the array data stored in the 
array file. 


4.2.2 The File Record 

The File Record is always the first physical record in an array file. It contains nine items in the 
following order: 

1. An identification word, “yyy/xxxx”, where “yyy” is a three character string indicating the file 
architecture and “xxxx” is a four character string indicating the type of data stored in the array 
file. For an SPK the file identification word is “DAF/SPK ”, for a text PCK it is “KPL/PCK ”, 
and for a binary PCK it is “DAF/PCK ”. 


2 . 

3. 

4. 

5. 

6 . 


The value of ND, the number of double precision components in each summary (H.l ). 


The value of NI, the number of integer components in each summary (H.l ). 

A 60 character internal name for the array file. 

The record number of the initial Summary Record in the file. 

The record number of the final Summary Record in the file. 

7. The first free address in the file: the address where the first element of the next array added to 
the file will be stored. 

8. A binary file format identification string. 

9. An FTP transmission corruption test string. 

The numerical values in the File Record are all stored as binary integers. The portion of the File 
Record which does not contain data is padded with the ASCII null character, < 000 >[^ 


The Binary File Format Identification String: The binary file format identification string is an 
eight character string identifying the order in which the binary data bytes were stored when written 
and the interpretation of the bits within the floating point number. Currently, there are four recog¬ 
nized formats: 


Throughout H.2.2 the value between the delimiters “<’ and “>’ is the numeric value of that byte. 
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3. 


“BIG — IEEE”: The IEEE format for floating point mantissa and exponent stored in big- 
endian order from most significant to least significant. 

“LTL — IEEE”: The IEEE format for floating point mantissa and exponent stored in little- 
endian order from least significant to most significant. 

“VAX — GELT”: Integers are stored in little-endian order, single precision floating point num¬ 


bers use the VAX E format, and double precision numbers use the VAX G format (NSSDC 
20T4a| . 

4. “VAX — BELT”: Integers are stored in little-endian order, single precision floating point num¬ 


bers use the VAX E format, and double precision numbers use the VAX D format (NSSDC 

2m4al). 


Other formats are available (NSSDC 2014b I, but these four formats predominate. In particular, 
little-endian order is the most common due to the pervasive use of the Intel x86 architecture ma¬ 
chines, which use a little-endian architecture (llntell 120041). 


The FTP Transmission Corruption Test String: If the user neglects to invoke the IMAGE (BI¬ 
NARY) transfer mode when transferring a binary file from one platform to another using the ETP 
protocol, an ASCII mode transfer may occur, and the file may become corrupted. The most likely 
corruption of a binary file is the possible substitution of one set of line terminators for another. Plac¬ 
ing a string that is a representative set of character sequences that are susceptible to corruption in 
the Pile Record makes it possible to trap and report any problems to the user if corrupted kernels are 
loaded at run time. Moving test binary files from one platform to another shows that the clusters of 
ASCII codes most likely to be corrupted are: 

• < 013 > - The text line terminator on older Macintosh-based platforms. 

• < 010 > - The text line terminator on UNIX-based platforms. 

• <013><010> - The text line terminator on Microsoft platforms. 

• < 013 >< 000 > - This sequence of characters maps into < 013 > on some UNIX-based 
systems (HP, SGI, NEXT). 

• < 129 > - Macintosh based systems permute ASCII values whose parity bit is set. Thus, 
ASCII values greater than 127 are altered. 

• < 016 >< 206 > - Some older ETP servers running Microsoft operating systems convert this 
sequence of ASCII codes to<016><016>< 206 >. 

These clusters may not be the complete set of clusters that may be corrupted through an improper 
ETP transfer. 

The substitution of one set of line terminators for another may result in expansion or compression 
of certain sequences of bytes. If the clusters are juxtaposed, new sequences of adjacent bytes, also 
subject to transformation, might be formed. The ETP transmission corruption test string is inserted 
so that it can be located in the event compression or expansion, either within the test string itself, or 
elsewhere in the file record, shifts it away from its default location. It also must include a mechanism 
to prevent interaction between the clusters. The solution is to bracket the entire test string with the 
start and stop identifiers ‘ETPSTR’ and ‘ENDETP’, and separate the clusters with the printable 
delimiter The ETP transmission corruption test string, inserted into the Pile Record starting with 
the 700th character, is: 


PTPSTR:< 013 >:< 010 >:< 013 >< 010 >: 

< 013 >< 000 >:< 129 >:< 016 >< 206 >:ENDPTP 
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This string may be modified in the future if other clusters of ASCII codes likely to be corrupted by 
an improper FTP transfer are discovered. 

4.2.3 The Comment Area 

The contents and formats of Comment Area are left entirely to the user, and may be left empty. The 
initial Comment Record is the second record of the file, and the final Comment Record immediately 
precedes the initial Summary Record of the file. Comment Records may be used to store any data 
desired by the file constructor. The Comment Area may contain only printable ASCII characters, 
specifically ASCII 32-126. 

The only limit on the line length in the Comment Area is: The number of characters must be 
representable by a FORTRAN integer. SPICE supports a line length of up to 255 characters. A 
shorter maximum line length, however, may enhance readability. 

4.2.4 Summary Records 

A Summary Record contains a maximum of 128 double precision words. The first three words of 
each Summary Record are reserved for the control items. They are: 

1. The record number of the next Summary Record in the file. (If this is the final Summary 
Record then the value is 0.) 

2. The record number of the previous Summary Record in the file. (If this is the initial Summary 
Record then the value is 0.) 

3. The number of summaries stored in this record. 

Although the control items are integer values, they are stored as double precision numbers. This 
allows Summary Records to be buffered using the same mechanism as Element Records, which 
contain only double precision numbers. 


The Summaries: The control items are followed immediately by the summaries. The number of 
summaries, NS, that can fit in a single Summary Record depends on the summary size SS, which is 


a function of NI and ND ((4.2.2). Using integer division. 


SS = ND + 


A/-t-l 


(3) 


Then 


NS = 


125 


(4) 


Each summary contains the ND double precision components followed by the NI integer com¬ 
ponents of the summary. The integer components are stored, in pairs, as equivalenced DOUBLE 


PRECISION numbers ((4.1). Thus, the integer components require a total of {NI -\- 1)/2 words of 
space, and the byte order depends on the system architecture. Figureshows the layout of the data 
within a summary with an odd number of integer components, and Fig. shows the layout of the 
data within a summary with an even number of integer components. 

The values of most of these components are up to the designer of the DAE type. The final two 
integer components, however, contain the initial and final addresses of the array ( §4.1.1 ). 

Summaries are never split across physical record boundaries. Thus, if the number of remaining 
bytes in the Summary Record are insufficient to hold a summary, they remain unused. 
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a. 

001 1 

ND \ ND+1 1 


1 ND + NI/2 1 ND + NI/2 + 1 

t 

T 



t 


1 

First Double Precision 

1 

Last Double Precision 



1 

Integer Components 


Component 

Component 



(NI-2) and (NI-1) 



First Tw( 

D Integer 

Integer Component 


Components 


Nl and empty 

b. 






001 

ND 

ND + 1 

ND + NI/2 


y—^ 

j 

> 

< 



1 

First Double Precision 

Last Double Precision 


1 

Last Two Integer 


Component 

Component 



Components 



First Two Integer 





Components 




Figure 1: a. An example of the format of words in a summary with an odd number of integer 
components, b. An example of the format of words in a summary with an even number of integer 
components. 


An example of a Summary Record is depicted in Fig. The value in each box corresponds to 
the address of the double precision word in the record. Fet SS = 3, so 


NS = 


125 

T 


= 41 


summaries can fit in the Summary Record. The first summary is stored in words 4 through SS + 3, 
the second summary is stored in words S5 + 4 through 2SS + 3, and so on. This uses a total of 126 
words, leaving two words empty. 


001 

002 

003 

004 

005 

006 


124 

125 

126 

127 

128 


T ^ 

L > 

>> A >1^, ^ 

AAA > 

V > k 

Next 


(Summary No. 1) 

,1 1 1 . 

(Summary No. 41) 


Previous 


Unused 


NSUM= 41 


Figure 2: An example of the format of words in a Summary Record. The record is divided into 
double precision words and, in this case, the number of words in a summary, SS, is three. 


4.2.5 Name Records 

Each Name Record contains a set of character strings to identify the arrays. A Name Record always 
follows a Summary Record so a new Name Record is added to the kernel each time a new Summary 
Record is added. The number of names in a Name Record is equal to the number of summaries in 
the corresponding Summary Record. The maximum length for a name in the Name Record, NC is 

NC = s(ND + ^^^^^j=SSS. (5) 
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An example of a Name Record is depicted in Fig. The numbers correspond to the number of 
the characters in the record. The first name is stored in characters 1 through NC; the second name is 
stored in characters NC + 1 through 2 AC; and so on. In this example SS = 3, so NS = 41 and 

AC = 8 X 3 = 24 

characters can fit in a name. This uses a total of 984 characters, leaving the characters beginning 
with 985 empty. 



001 002 ... 024 025 ... 04 

8 ... 961 

984 985 ... 

n 

1 

(Name Number 1) 

rn 

(Name Number 

ft T 1 

2) ... (Name Number41) L 

t 

Jnused 


Figure 3: An example of the format of characters in a Name Record. The record is divided into 
characters and, in this case, the number of characters in a name, AC, is 8 SS = 24. 


4.2.6 Element Records 

Most of the records in an array file are Element Records. Element Records hold the elements of the 
arrays stored in the file. Each Element Record has room for 128 double precision numbers. A record 
that immediately precedes a Summary Record or is the last record of a file may be partially filled. 

All elements belonging to the same array are stored contiguously. An array may span multiple 
Element Records. If an array extends beyond the end of an Element Record, the element immediately 
following the last address in that Element Record is placed in the first address of the next Element 
Record. 

The elements stored in an Element Record may belong to more than one array. Fig. shows an 
Element Record containing three arrays: A, B, and C. Array A has 10 elements, array B has 100 
elements, and array C has 20 elements. 


Element Record n 


Element Record n + 1 


001 

002 


0] 

LO 

0] 

LI 


1] 

LO 

11 

.1 


128 


y- 

[1] A[2] 


A[] 


0] B[l] 


B[100] C[l] 


C[ 


8 ] 


001 


C[ 


002 

X 

9] C[20] 


Figure 4: An example of an Element Record. The record is divided into double precision words. In 
this case, the record contains three arrays. A, B, and C. Array A contains 10 elements, array B 100 
elements, and array C 20 elements. 


4.2.7 An SPK Example 

This example illustrates the use of addresses and lists within an SPK showing how one file may be 
created, and how arrays may be added to that file. 
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The following notation will be used for items defined in the File Record: 

• IDWORD is the identification word, 

• ND and NI are the number of double precision and integer values used to define the format of 
the file, 

• RI and RF are the record numbers of the initial and final Summary Records in the file, and 

• FFA is the first free address in the file. 

• NEXT and PREV are the record numbers of the next and previous Summary Records in the 
file, and 

• NSUM is the number of summaries stored in the record. 


Details on these parameters may be found in ^4.2.2 and ^4.2.4 


The IDWORD written to the new file is the concatenation of the string “DAF/” with the kernel 
type string, and must contain eight characters. For an SPK, the IDWORD written to the new file is 
“DAF/SPK ” where the eighth character of the IDWORD is a blank character. 

For SPK kernels, the value for ND = 2 and for NI = 6. The meanings for the double precision 


and integer components of an SPK Summary Record are discussed in ^ 5.1 The summary size, SS is 


SS = ND + ^^^^^ = 2 + 3 = 5, 


so each segment summary requires 5 double precision words of storage, so NSUMmqx^ the number 
of summaries each Summary Record can hold 

125 125 

NSU Mmux = = 25 


summaries. 

Figure]^ shows the layout of a typical SPK Summary Record. 


001 

002 

003 

004 

■ ■ ■ 

008 

009 

■ ■ ■ 

013 

■ ■ ■ 

123 

■ ■ • 

128 

t ' 

< 

> 


t T T 


Next 

Previous 


(Summary No. 1) (Summary No. 2) 


(Summary No. 25) 


NSUM 


Figure 5: An example of an SPK Summary Record where ND = 2 and NI = 6, so SS = 5 and 
NSUMMax = 25. 

The number of names that a Name Record can hold is equal to the number of summaries that the 
Summary Record can hold. Here it is 25, and the number of characters in each name array is 

A^C = 85S = 8x5=40. 

Thus, the Name Record, which immediately follows each Summary Record, has space reserved as 
shown in Fig. 

Assume that the number of Comment Records is 10. Then, the File Record information is stored 
in record 1, the Comment Record data are stored in records 2 through 11, and the initial Summary 
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0001 

... 

0040 

0041 

... 

0080 

... 

0961 

... 

1000 

1001 

... 

1024 


(Name Number 1) (Name Number 2) (Name Number 25) Unused 


Figure 6: An example of an SPK Name Record where ND = 2 and NI = 6. Thus, NSUMmox = 25 
so AC = 40. 

Record is record 12. If the file is empty, the initial Summary Record, RI, is also the final Summary 
Record, RF: 


RI = RF = 12 


The first Name Record for the file is immediately after the Summary Record, in record 13. Thus, the 
first free address, FFA, in the file is the first word in record 14: 


FFA = w + (r-l)*128 = 1 + (14- 1) * 128 = 1665 


where w is the word number and r is the record number. 

The File Record also contains an internal file name of up to 60 characters. For this example 
the internal file name will be “TESTFIFE”. For the rest of this example, the binary file format 
identification string and the FTP transmission corruption string ( §4.2.2 ) will be ignored. The File 
Record will be represented by a collection of values enclosed by braces and preceded by its record 
number, r: 


r { IDWORD = x,ND = a, NI = b, IFNAME = c,RI = d, RF = e, FFA = / }. 

where x, a, b, c, d, e, and / are appropriate values. The File Record for this example file is initially: 

1 { IDWORD = “DAF/SPK ”, ND = 2,NI = 6, IFNAME = “TESTFIFE”, RI = 12, 

RE = 12, EEA = 1665 }. 

There is only one Summary Record, and the file contains no arrays. Thus, the values of NEXT, 
PREV, and NSUM in the Summary Record are all initially zero. For the rest of the example, each 
Summary Record will be represented by a collection of values enclosed by angle brackets and pre¬ 
ceded by its record number: 


r < NEXT = a, PREV = b, NSUM = c, (d, e), (/, g), ..., (h, i) > 


where a, b, and c are integers and the ordered pairs enclosed in parentheses are the initial and final 
addresses of the arrays whose summaries are contained in the record. The remaining components 
of each summary are ignored to make the example easier to follow. Thus, the first, and so far only. 
Summary Record for this example file is initially: 


12 < NEXT = 0, PREV = 0, NSUM = 0, (0, 0), (0, 0),..., (0, 0) >. 


Name Records will be represented by 
r < “n” >, 


where n is the number of names it currently contains, and Element Records will be represented by 
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r <N > 

where N is the number of elements stored in the record. 

Once the initial Summary and Name Records have been written, the file looks like this: 

1 { IDWORD = “DAF/SPK ”, ND = 2,NI = 6, IFNAME = “TESTFILE”, RI = 12, 

RF = 12, FFA = 1665 } 

2 

. Records 2 through 11 are the comment area. 

11 

12 < NEXT = 0, PREV = 0, NSUM = 0, (0, 0), (0, 0),..., (0, 0)> 

13 < “0” > 

An array Al, containing 100 elements, is added to the file. This array will be stored contiguously, 
beginning at the first free address. Thus, its initial and final addresses will be 1665 and 1764, 
respectively. The entire array fits into a single record, so one Element Record is added to the file. 
The value of NSUM in the Summary Record is incremented by one. The new value of FFA is the 
address following the final address of the new array: 1765. After Ai is added, the file is now 

1 { IDWORD = “DAF/SPK ”, ND = 2,N1 = 6, IFNAME = “TESTFIEE”, Rl = 12, 

RF =12, FFA = 1765 } 

2 

. Records 2 through 11 are the comment area. 

11 

12 < NEXT = 0, PREV = 0, NSUM = 1, (1665, 1764), (0, 0),..., (0, 0) > 

13 < “1” > 

14 < 100 > 100 words for Al. 

A second array A 2 , containing 200 elements, is added to the file. The initial and final addresses 
of A 2 will be 1765 and 1964. This array will fill the remainder of the first Element Record, all of the 
second record, and part of the third. Thus, two Element Records are added to the file. The value of 
NSUM in the Summary Record is again incremented, and the new value of FFA = 1965 is stored in 
the File Record. The file is now: 

1 { IDWORD = “DAF/SPK ”, ND = 2,N1 = 6, IFNAME = “TESTFIEE”, Rl = 12, 

RF = 12, FFA = 1965 } 

2 

. Records 2 through 11 are the comment area. 

11 

12 < NEXT = 0, PREV = 0, NSUM = 2, (1665, 1764), (1765, 1964),..., (0, 0) > 

13 < “2” > 

14 < 128 > 100 words for Al, 28 words for A 2 

15 < 128 > 128 words for A 2 

16 < 44 > 44 words for A 2 
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For arrays A 3 through A 24 , each containing 10 elements, the process is repeated. These will take 
up addresses 1965 through 2184. They will fill the remainder of the third Element Record, all of the 
fourth Element Record, and the first 48 words of the fifth Element Record. The file is now: 

1 { IDWORD = “DAF/SPK ”, ND = 2,NI = 6 , IFNAME = “TESTFIEE”, RI = 12, 

RF = 12, FFA = 2185 } 

2 

. Records 2 through 11 are the comment area. 

11 

12 < NEXT = 0, PREV = 0, NSUM = 24, (1665, 1764), (1765, 1964),..., (2175, 2184), 

( 0 , 0 ) > 

13 < “24” > 

14 < 128 > 100 words for Al, 28 words for A 2 

15 < 128 > 128 words for A 2 

16 < 128 > 44 words for A 2 , 10 words each for At,-Aiq, and 4 words of Ah 

17 < 128 > 6 words for Ah, 10 words each for Ai 2 ~A 23 , and 2 words of A 24 

18 < 48 > 8 words for A 2 A. 

Eet array A 25 contain 150 elements. Its initial and final addresses are 2185 and 2334. The array 
fills the remainder of the fifth Element Record, and part of a sixth, so one new Element Record is 
added. And the value of NSUM is in the Summary Record is incremented. The final Summary 
Record is now full. Thus, the following adjustments are made to allow new data to be added to the 
file: 

1. New Summary and Name Records are added to the file. 

2. The value of NEXT in the old Summary Record is set to the record number of the new Sum¬ 
mary record, in this case 20 . 

3. The value of PREV in the new Summary Record is set to the record number of the old Sum¬ 
mary record, in this case 12 . 

4. The File Record is updated so that the value of RF points to the new final Summary Record. 

5. The value of FFA in the File Record points to address 2689, the first word in the first Element 
Record following the new Name Record. 

The previous Element Record, record 19, will remain only partially filled. 

1 { IDWORD = “DAF/SPK ”, ND = 2,N1 = 6 , IFNAME = “TESTFIEE”, Rl = 12, 

RF = 20, FFA = 2689 } 

2 

. Records 2 through 11 are the comment area. 

11 

12 < NEXT=20, PREV=0, NSUM=3, (1665, 1764), (1765, 1964),..., (2185, 2334)> 

13 < “25” > 

14 < 128 > 100 words for Al, 28 words for A 2 

15 < 128 > 128 words for A 2 

16 < 128 > 44 words for A 2 , 10 words each for At,-Aiq, and 4 words of Ah 

17 < 128 > 6 words for An, 10 words each for Ai 2 ~A 23 , and 2 words of A 24 

18 < 128 > 8 words for A 24 and 120 words for A 25 
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19 < 30 > 30 words for A 25 . 

20 < NEXT = 0, PREV = 12, NSUM = 0, (0, 0), (0, 0),(0, 0) > 

21 < “ 0 ” > 

Adding more arrays then continues with a new Element Record as record 22. As additional data 
are added to the file: 

• Element Records are added as necessary. 

• Summary and Name Records are updated. 

• When the final Summary Record is filled: 

- New Summary and Name Records are added. 

- The value of RE is updated. 

• The value of EEA is updated. 


5 The SPK Format 


The SPK format was developed specifically to store position ephemerides of objects. Each SPK 
kernel contains a number of segments ( §5.1 1 consisting of an ephemeris for a single object. The file 
identification word for an SPK kernel is “DAF/SPK ”. 


5.1 Segments 

An SPK segment consists of a DAP array in an SPK kernel. A kernel may contain one or more 
segments. Each segment contains data sufficient to determine the ephemeris of an object in a spec¬ 
ified reference frame. All the data in a segment consists of a single SPK type, but multiple SPK 


types may occur in a single SPK kernel. The associated segment summary (^4.1) has two double 


precision components {ND = 2), and six integer components (NI = 6). Thus, the maximum number 
of characters in a name is (using integer arithmetic) 


NC = 8 2-h 


6 + 1 


= 40 


characters. 

The double precision components of the summary are: 

1 . the initial epoch and 

2 . the final epoch 

of the interval for which data are contained in the segment, on the TDB time scale from J2000.0 
(JD 2451545.0). The initial and final epochs are always given as seconds from J2000.0 even when 
the time argument used in the segment is TCB. The time argument for the data in the segment, when 
expressed using the TDB time scale, must be between these two values. 

The integer components of the summary are: 


the NAIP object identification number ( §5.1.1| ) of the target body, 

the NAIP object identification code of the center, 

the NAIP integer code ( §5.1.2[ ) for the reference frame,. 

the integer code for the SPK data type ( §5.2[ ), 

the initial address of the array, and 
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The first two integer components of the summary are discussed in §5.1.1| The third integer component 
is discussed in f 5.1.2 The fourth integer component is discussed in §5.2[ And the last last two integer 


components are discussed in f 4.1.1 


Segments within an SPK need not be ordered according to time. Segments providing data for a 
later time period may precede segments covering an earlier time period. In SPICE, segment order 
implies priority. Eor a given object, segment priority increases with distance from the beginning 
of the file: segments closer to the end of the file have higher priority than segments for the same 
target body that occur earlier in the file. When a data request for a specified target body is made, 
the segment whose time interval includes the requested time with highest priority will be selected 
to satisfy the request. This priority scheme will cause a higher priority segment for a target body to 
mask a lower priority segment for the same body over the intersection of the coverage intervals of 
the two segments. 


5.1.1 NAIF Object Identification Numbers 

The first integer component of the summary is the NAIF object identification number for the ephem- 
eris object. Each object in the solar system is assigned a unique identification number. Eor example, 
the identification number for Jupiter is 599 and the identification number for the Sun’s center is 
10. Thus, the target body and center for the heliocentric ephemeris of Jupiter are 599 and 10, re¬ 
spectively. Similarly, the identification number for Jupiter’s barycenteij^ is 5 and the identification 
number for the solar system barycenter is 0. Thus, the target body and center for the heliocentric 
ephemeris of Jupiter’s barycenter about the solar system barycenter are 5 and 0, respectively. Ap¬ 
pendix 1^ details how these numbers are assigned. The tables in Appendix give the available 
identification numbers recognized by SPICE at the time this report was written. 

Often it is more convenient to give the ephemeris of an object with respect to a nearby object 
rather than with respect to the origin of the reference frame. Eor example, the Moon’s ephemeris 
may be referred to the ICRS but the coordinates may be given with respect to the geocenter. The 
second integer component is the NAIE identification number for the reference object from which the 
ephemeris object’s ephemeris is offset. 


5.1.2 Recognized Reference Frames 


The third integer component of the SPK summary is the NAIF code for the reference frame. Refer¬ 
ence frames may be either inertial or non-inertial. 

Most of the inertial reference frames recognized are for specific JPE ephemerides and are of little 
interest in the present context. The identification number for the International Celestial Reference 
System, henceforth ICRSp^ is 1 and its name is “J2000”. Other currently recognized, “built-in” 
inertial reference frame names and their identity numbers, found in |Semenov|(|2010b|), are given in 
Table H 

The currently recognized “built-in” non-inertial reference frame names are found in [Semenov 
(2010b). The identity numbers of those reference frames of interest are tabulated in Table 


Semenov (2010b) also describes how to specify additional reference frames. These reference 


frames may be either inertial or non-inertial. 

^There is a conceptual difference between the center of mass of a planet and a planet satellite system even when 


the planet has no satellites ([ A.l i Hence, the ephemeris of a planet is not identical to the ephemeris of a planet-satellite 
system barycenter and require separate object identification numbers. 

^'’Although it is called the International Celestial Reference System, the ICRS is consistent with the object called a 
reference/rame in SPICE. 
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Table 2: Selected available inertial reference frame names (ISemenovj |2010b|). 


Frame Name 


Description 


ID No. 


J2000 Earth mean equator, dynamical equinox of 12000.0“ 1 

B1950 Earth mean equator, dynamical equinox of B 1950.0 2 

FK4 Fundamental Catalog (4) 3 

GAEACTIC Galactic System II 13 

ECEIPJ2000 Earth mean ecliptic and equinox of the Julian epoch J2000.0 17 

ECEIPB1950 Earth mean ecliptic and equinox of the Besselian epoch B 1950.0 18 

“This reference frame is taken to be identical with the International Celestial Reference 


System (ICRS). 


Table 3: Selected available non-inertial reference frame names {Bachman] |2007i|2008|). 


Frame Name 

Description 

ID No. 

IAU_EARTH 

The geocenter 

10013 

lAU MARS 

Mars’ center 

10014 

lAUJUPITER 

Jupiter’s center 

10015 

IAU_SATURN 

Saturn’s center 

10016 

lAU.URANUS 

Uranus’ center 

10017 

IAU_NEPTUNE 

Neptune’s center 

10018 

IAU_PEUTO 

Pluto’s center 

10019 

ITRF93 

International Terrestrial Reference Frame 1993“ 

13000 

MOONJ^A 

Generic lunar axes of the principal moments of inertia^ 

31000 

MOONAIE 

Generic lunar mean Earth-mean pole of rotation axes^ 

31001 

MOONJJAT)E421 

DE421 lunar axes of the principal moments of inertia 

31006 

M00NA1E DE421 

DE421 lunar mean Earth-mean pole of rotation*^ 

31007 


“Available as a generic kernel from NAIF. 
h 

The generic lunar orientation ephemerides are not as 
may be linked to a specific ephemerides by SPICE, 36.2.1|Bachman| 

“a constant offset rotation matrix from the axes of the lunar principal moments of iner tia is used to 


recific lunar ephemeris. They 
20081. 


specify the lunar mean Earth-mean pole of rotation reference frame (Bachman 


2008 I. 
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5.2 SPK Chebyshev Data Types 


SPK kernels use multiple data types to store the ephemeris data. Like the solar system bodies, each 
data type is recognized by an identification number. SPICE currently has reserved identification 
numbers for 24 data types in the SPK. These are types 1 through 21, 102, 103, and 120. Kernels 
that do not use the correct format for these data types will not be correctly interpreted by SPICE or 
other readers of these kernels. NAIE may also reserve other data types in the future. SPK data type 
identifiers 901 through 910 have been set aside for user defined data types. 


Only the six types that use Chebyshev polynomials of the first kind (e.g. Rivlin 19741 are of 
interest herep^ They are: 

• Type 2. Chebyshev polynomials (position only): These are sets of coefficients for the X, Y, 
and Z rectangular coordinates of the body position. The velocity of the body is obtained by 
differentiation of the Chebyshev polynomials. The time argument for these ephemerides uses 
the TDB time scale. The details of ordering of data in Type 2 kernels is given in §5.3.2 


Type 3. Chebyshev polynomials (position and velocity): These are sets of coefficients for the 
X, Y, and Z rectangular coordinates of the body position, and the corresponding components 
of the velocity. The time argument for these ephemerides uses the TDB time scale. The details 
of ordering of data in Type 3 kernels is given in §5.3.3 


Type 20. Chebyshev polynomials (velocity only): These are sets of coefficients for the X, Y, 
and Z, the time derivatives of the rectangular coordinates of the body position. The position 
of the body is obtained by integration of the Chebysev polynomials and addition of a stored 
constant of integration. Chebyshev polynomials of velocity are used in the EPM ephemerides. 
The time argument for these ephemerides uses the TDB time scale. The details of ordering of 
data in Type 20 kernels is given in §5.3.4[ 

Type 102. Chebyshev polynomials (TCB: position only): This type is identical to Type 2 
except the time argument uses the TCB time scale rather than the TDB time scale. The details 
of ordering of data in Type 102 kernels is given in ^ 5.3.2[ 

Type 103. Chebyshev polynomials (TCB: position and velocity): This type is identical to 
Type 3 except that the time argument uses the TCB time scale rather than the TDB time scale. 


The details of ordering of data in Type 103 kernels is given in (5.3.3 


• Type 120. Chebyshev polynomials (velocity only): This type is identical to Type 20 except 
the time argument uses the TCB time scale rather than the TDB time scale. The details of 
ordering of data in Type 120 kernels is given in §5.3.4[ 

Each segment contains an arbitrary number of logical records. The total number of array ad¬ 
dresses available by a kernel (Q is the only restriction on length. Each record contains a set of 
Chebyshev coefficients valid throughout a fixed length time interval. The maximum Chebyshev 
polynomial degree is the same for each component and fixed for the segment; all records in the 
segment contain the same number of coefficients. 


5.3 The Individual Kernel Types 

5.3.1 The Segment Structure for Types 2, 3,102, and 103 


Eigure 1^ shows the segment structure for file types 2, 3, 102, and 103. Records are ordered by 
increasing initial epoch. Located at the end of the segment is a directory of four numerical values. 


^^These types are also used for binary PCKs; however, they are used to store orientation data in binary PCK 6.2.2 1 
and positional data in SPKs. 
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This directory contains the data required to determine the location and evaluate the record for a 
particular epoch: 

1. INIT: The initial epoch of the first record, given in seconds from J2000.0 (JD 2451545.0). 

2. INTLEN: The length of the interval covered by each record, in seconds. 

3. RSIZE: The total number of array elements in each record. 

4. N: The number of records contained in the segment. 

The maximum degree of the Chebyshev polynomial, PD, for a segment is deduced from the value 
of RSIZE. 

The coefficients for each coordinate position or velocity in a record are stored together, in order, 
from the 0th to the PDth degree Chebyshev polynomial coefficient. If the nth degree Chebyshev 
polynomial is not used, its coefficient must be present and set to 0. 


Record 1 

Record 2 


Record N 

INIT 

INTLEN 

RSIZE 

N 


Figure 7: The structure of a data segment for a Chebyshev polynomial, equal record length, SPK. 


5.3.2 Type 2: Chebyshev Polynomials (Position Only) and Type 102: Chebyshev Polynomials 
(TCB: Position Only) 

The types 2 and 102 SPK data type contains Chebyshev polynomial coefficients for the position of 
the body as a function of time. For types 2 and 102 modulo {RSIZE — 2,3) = 0, so 


PD 


RSIZE - 2 


( 6 ) 


Each record begins with the values for the parameters MID and RADIUS followed by the Cheby¬ 
shev polynomial coefficients for X, Y, and Z coordinate in that order. This arrangement is shown 
schematically in Fig.jS] For a Chebyshev polynomial, Ch„{t), the independent variable t runs contin¬ 
uously from t — io t = 1. MID is the midpoint of the ephemeris time interval covered by the set 
of coefficients, T, in seconds from J2000.0. At MID t = 0. And RADIUS, is the range, in seconds, 
from the midpoint to the beginning or end of the interval covered by coefficients in the record. These 
parameters are used to map between T, MID — RADIU S <T < MID 4- RADIU S, and t, —\ <t <\. 


MID 

RADIUS 

X Coefficients 

Y Coefficients 

Z Coefficients 


Figure 8: The structure of the record for a Type 2: Chebyshev Polynomials (position only) SPK data 
segment. 


The difference between type 2 and type 102 segments is: The independent argument for type 2 
segments is seconds from J2000.0 on the TDB time scale, while the independent argument for type 
102 segments is seconds from J2000.0 on the TCB time scale. The time limits given for both types 
in the Segment Summary (§4.2.4[), however, are given on the TDB time scale. 
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5.3.3 Type 3: Chebyshev Polynomials (Position and Velocity) and Type 103: Chebyshev Poly¬ 
nomials (TCB: Position and Velocity) kernels 


The types 3 and 103 SPK data type contains separate Chebyshev polynomial coefficients for the 
position and velocity of the body as a function of time. The structure of the segment is similar to that 
of the SPK data types 2 and 102. The only difference is that each logical record (see Fig.|^ contains 
six sets of coefficients instead of three. Thus, for types 3 and 103 modulo {RSIZE — 2,6) = 0, so 


PD 


RSIZE - 2 
6 


- 1 . 


(7) 


MID 

RADIUS 

X Coeff. 

Y Coeff. 

Z Coeff. 

X Coeff. 

Y Coeff. 

Z Coeff. 


Figure 9: The structure of the record for a Type 3: Chebyshev Polynomials (position and velocity) 
SPK data segment. 


The difference between type 3 and type 103 segments is: The independent argument for type 3 
segments is seconds from J2000.0 on the TDB time scale, while the independent argument for type 
103 segments is seconds from J2000.0 on the TCB time scale. The time limits given for both types 
in the Segment Summary (§4.2.4), however, are given on the TDB time scale. 


5.3.4 Type 20: Cbebysbev Polynomials (Velocity Only) and Type 120: Cbebysbev Polynomi¬ 
als (TCB:Velocity Only) 


The structure of Type 20 (Velocity Only) andType 120 (TCB:Velocity Only) data segments, dis¬ 


played in Fig. 10 are different from the other Chebyshev polynomial data segments. The parameters 


at the end of the data segment are: 

• DSC ALE ■. the distance scale in kilometers, 

• TSCALE', the time scale in seconds, 

• INIT JD: the integer part of the Julian Date of the initial record, 

• INITER: the fractional part of the Julian Date of the initial record, 

• INTLEN: the time period covered by each record in Julian days, 

• RSIZE : the total number of array elements in each record 


RSIZE = 3 {PD+\) 


( 8 ) 


where PD is the degree of the Chebyshev polynomial, and 
• A: the number of records in the segment. 

The Type 20 SPK data type contains Chebyshev polynomial coefficients for the velocity of the 
body as a function of time plus its position at the time of the mid-point of a record. The Chebyshev 
polynomials are evaluated using the independent argument t, where — 1 < t < 1 over each record. 
The value of t is determined from the input time T using 


Tjd — 

0.^.^^+2451545.0 


86,400 

To = 

Tjd - {INITJD -f INIT PR) 


To 


INTLEN 
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Record 1 

Record 2 

Record 3 

■ ■ ■ 

Record N 

DSCALE 








TSCALE 

INITJD 

INITFR 

INTLEN 

RSIZE 

N 









Figure 10: The structure of the record for a Type 20: Chebyshev Polynomials (velocity only) SPK 
data segment. 


Ti = To-mxINTLEN 

2Ti 

t = -^-1 

INTLEN 

where T is in seconds from J2000.0, m is an integer, and Tjo, Tq, and T\ are real values. 


X Coeff. 


X(t = 0) 


Y Coeff. 


V^(t = 0) 


Z Coeff. 


Z(t = 0) 


Figure 11: The structure of the record for a Type 20: Chebyshev Polynomials (velocity only) SPK 
data segment. 


Each record contains the Chebyshev polynomial coefficients for X, Y, and Z velocity. The ve¬ 
locity coefficient for each component is followed immediately by the position component value at 
t = 0. This arrangement is shown schematically in Fig. 11 For a Chebyshev polynomial, Ch„{t), 
the independent variable t runs continuously from t — — \ io t = 1. JD{t = 0), the Julian Date of 
midpoint of a record is inferred from 


JD(t = 0) = INITJD + INITER + INTLEN (m - 1/2). (10) 

where (m — 1/2) is a real value. The units for the positions at t = 0 are DSC ALE km, and the 
velocities are DSC ALE / T SCALE km s ^ 

The polynomial degree is fixed, so all records have the same number of parameters, so RSIZE is 


RSIZE = 3{PD + 2). 


( 11 ) 


The difference between type 20 and type 120 segments is: The independent argument for type 
20 segments is seconds from J2000.0 on the TDB time scale, while the independent argument for 
type 120 segments is seconds from J2000.0 on the TCB time scale. The time limits given for both 
types in the Segment Summary (§4.2.4), however, are given on the TDB time scale. 


6 PCK Kernels 

PCKs are designed to supply planetary cartographic and physical constants such as planet orienta¬ 
tion, masses, triaxial shape models, and gravitational parameters. PCK files may store either text or 
binary data. However, text and binary PCK files have different formats, so both text and binary data 
may not be stored in the same file. 
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Most of these data consist of a limited number of single values, short vectors, and small matrices, 
which are easily stored as text. NAIF supplies a text PCK ( [Bachman 20111 with the constants 
recommended by the lAU’s Working Group on Cartographic Coordinates and Rotational Elements 
( Archinal et al.[ 2011a|b| ) to generate orientation ephemerides for major solar system bodies. The 
format of text PCK files is specified in §6.1| 

Other supporting data are not easily stored as text. In particular, the orientations of the Earth 
and Moon as a function of time are complex and required to high accuracy. Thus, their orientation 
ephemerides are represented using Chebyshev polynomials. These polynomials may be stored in a 
binary PCK to both save storage and speed up evaluation. The format for binary PCKs is discussed 


in ^6.2 


6.1 Text PCKs 


Text PCKs conform to a flexible format called “NAIF text kernel” format. The first line of a text 
PCK must consist solely of the file identification word, “KPL/PCK ” starting on the first character of 
the line. These kernels are ASCII files designed so they may be read and modified using a text editor. 
Text PCKs may be used for a variety of functions, in addition to storing orientation ephemerides and 


supporting data described here. For more information see Wright & Acton (20131. 

A text PCK consists of blocks (sets of contiguous lines) of comments, alternating with blocks of 
kernel variable assignments. A kernel variable consists of an identifying label called a “name string” 
and its value. Three kinds of data that can be placed in NAIF text kernel files: 

1. Character strings. 

2. Numerical values, stored as double precision numbers. 

3. Time values, stored as seconds from J2000.0. 

Double precision number data may consist of scalars, vectors, or matrices. Values are associated 
with name strings using a “name string = value” format. The name strings, together with their 
associated values, are called “kernel variables”. 

Comment blocks begin with the control sequence (a string alone on a line) 


\begintext 


Data blocks begin with the control sequence 
\begindata 

In a text kernel file, the lines preceding the first \begindata control sequence constitute a comment 
block. A \begintext control sequence is optional for this comment block. 

Except for non-printing characters or lines that can be interpreted as control sequences the text 
of comment blocks is arbitrary. 

Data blocks must appear in the form of an assignment such as 


NAME = ( VALUEl, VALUE2, ... ) 


where NAME is a case sensitive string no longer than 32 characters. The values on the right hand side 
may be either numeric values or character strings. Numeric values may be either integer or floating 
point values. Character string values are normally limited to 80 characters in length and are single 
quoted. For example 

B0DY399_RADII = ( 6378.140 6378.140 6356.75 ) 
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• Vector data values are separated by commas or blanks, but not by tabs. 

• The right hand side of the assignment can be continued over multiple lines. 

• Numeric values can be expressed as integers or reals. 

• Real values may be expressed in fixed point or scientific notation. 

• Scientific notation may use either “E” or “D” to delimit the exponent and is not case sensitive. 

• Vector data values are enclosed in parentheses. 

• Assignments of scalars do not require the value to be enclosed in parentheses, but that notation 
is frequently used as a visual cue. 

• Blank lines within or between assignments are ignored. 

• Time values may be assigned using the “@” character to identify it as a time value. 
Non-printing characters including tab should not be present in the file: the presence of such charac¬ 
ters may cause formatting errors when the file is viewed. 


6.1.1 Text PCK Variable Names 


Variable names are case-sensitive and must not exceed 32 characters in length. They may include 


any printable character (Bachman 2014b I except: 


space, ; 
period,".”; 
parentheses,“(” or 
equal sign,“=”; or 


• the TAB character. 

Not using the Plus sign, “-r”, as the last character is recommended. 

Within SPICE variable names that do not have the expected case will be invisible to SPICEEIB 
routines that try to fetch their values. SPICE routines that use kernel variables accept only upper 
case names, so NAIE recommends upper case always be used for variable names. 

Within SPICE text PCK variables follow the pattern: variables related to a body whose NAIE 
integer code is nnn have names of the form 


B0DYnnn_<item name> 


where <iteni name> is a short string that identifies the type of quantity the kernel variable repre¬ 
sents. Eor example, the variable containing quadratic polynomial coefficients for the right ascension 
of the Earth’s north pole is 

B0DY399_P0LE_RA 


Those not using SPICE may adopt their own convention for identifying bodies. 


6.1.2 Models for the Orientation of Solar System Bodies 


PCK kernels contain the physical and cartographic parameters required to describe extended solar 
system bodies, examples of data appropriate for inclusion in PCKs are radii of bodies, constants 
defining orientation models, masses or values of CM. 

Eor the Sun, planets, and satellites, these parameters are denoted by: 

• BODYrmn.GM - The mass times the gravitational constant in km^ s“ 


B0DYrmn_P0LE_RA - The right ascension of the pole of orientatior 


12 


^^For the Sun, planets and satellites, the pole of orientation is the north pole, dehned as the pole on the north side of 
the invariable plane of the solar system. For dwarf planets, minor planets, and comets the pole of orientation is the pole 


around which the body rotates in a counterclockwise direction (Archinal et al. 201 la i. 
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BODYrmn_POLE_DEC - The declination of the pole of orientation. 
BODYrmn_PM - The prime meridian locatior 


13 


• BODYrmn_NUT_PREC_RA - The amplitudes of the components of nutation of the pole in right 
ascension. 

• BODYrmn_NUT_PREC_DEC - The amplitudes of the components of nutation of the pole in decli¬ 
nation. 

• BODYrmn_NUT_PREC_PM - The amplitudes arising from the components of nutation to the rota¬ 
tion of the body. 

• BODY b b b_NUT_PREC_ANGLES - The value at epoch and time rate of change of the body nutation 
angles (See below). 

The value of nnn is the NAIF identification number for the body whose orientation is being de¬ 
scribed. The value of bbb in BODY &bb_NUT_PREC .ANGLES is that of the body-satellite system barycen- 
ter for which the nutation angles are valid. 


Body Orientation: The orientation of solar system bodies is represented by three angles: a and d 
are the right ascension and declination of a body’s pole of orientatiorp] and W is the prime meridian 
location angle, measured in the counterclockwise direction about the body’s pole of orientation, from 
the vector resulting from the cross product of the unit vector pointing towards the north pole of the 
ICRS and the unit vector pointing towards the body’s pole of orientation at time t. The expressions 
used in text PCK files for the direction of the pole of orientation and prime meridian location consists 
of the sum of a quadratic polynomial part and a periodic part. The general form is 


Xit X 2 t^ f sm 9i for a and W 

A = Ao -h —- -t- n s 

T [ cos Oi for 5 


( 12 ) 


where t is the ephemeris time in seconds from the reference epoch, Aq, Xi, and A 2 , are the coefficients 
for the polynomial portion of the body’s motion, Xi is the array of coefficients for the periodic portion, 
and 9i is the array of periodic angles. 

• For a and 5 the polynomial portion represents the secular precession of the pole of the body, 
and the periodic part represents the nutation of the pole. The value of T = 3,155,760,000, the 
number of seconds in a Julian century. 

• For W, the polynomial represents the rotation of the body with respect to the ICRS and the 
periodic part represents librations in the rotation. The value of T = 86,400, the number of 
seconds in a day. 


The Nutation/Libration Angles: The nutation/libration angles, 0,, which form the periodic por¬ 
tion of solar system bodies, arise from the spin-orbit coupling between the body of interest and other 
solar system bodies. Usually, only the torque of the central body and satellites of a body-satellite 
system are large enough to be significant. Thus, their values are given using the body-satellite 
barycenter as the reference. The angles are represented by OiQ, the value of 0, at the epoch J2000.0, 
and Oil, its time rate of change. The value of 0,, in degrees, at time t is given by 


0; — 0iO + 


0 / 1 1 


(13) 


^^The position of the prime meridian is measured in the counterclockwise direction, from the vector resulting from 
the cross product of the unit vector pointing towards the north pole of the ICRS and pointing towards the body’s pole of 
orientation at time t jArchinal et al. 201 la|. 


14 


See footnote 
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where the value of T = 3,155,760,000, the number of seconds in a Julian century. 

All of the nutation angles for a body-satellite system may not apply to all of the orientation 
parameters. If the zth periodic component does not affect a parameter, its amplitude Xi = 0. 

6.1.3 The Radii of Solar System Bodies 

The radii of solar system bodies are given as a triplet to allow for triaxial shapes. The naming 
convention is B0DYnnn_RADII. The radii are those of the body-fixed X, Y, and Z-axes in units of 
kilometers. 

6.1.4 Epoch and Frame Specification 

By default, the orientation model parameters used in PCKs are assumed to define the transformation 
of vectors expressed in a base reference frame (normally the ICRS) to a body-fixed reference frame. 
The orientation of the latter frame is evaluated at t seconds from the epoch J2000.0. This transfor¬ 
mation is given in the form of a rotation, R{t). On those rare occasions where needed, the default 
values for the epoch and frame of the constants may be overridden. For example, it is possible to use 
constants referenced to the B1950 frame or the J1950 epoch. 

The default reference frame and reference epoch for a body are overridden by setting the values 
of the kernel variables 

BODY rmn_CONSTANTS_REF .FRAME 


and 


BODY rmn.CONSTANTS.JED .EPOCH 


where nnn is the NAIF identification number for the planet-satellite barycenter or, for other objects, 
the identification number of the body itself. 

The values of the frame specifier variable 

BODY rmn_CONSTANTS_REF .FRAME 


are the codes for the reference frames recognized by SPICE ((5.1.2). 

For example, to use constants referenced to the FK4 frame for the asteroid Gaspra (Body Identi¬ 
fication Number = 9511010), a text PCK containing the constants should include the assignment 


B0DY9511010_C0NSTANTS_REF.FRAME = ( 3 ) 


The values of the epoch specifier variable 
B0DYrmn.C0NSTANTS.JED.EP0CH 


are Julian ephemeris dates. To use constants for Gaspra referenced to the J 1950.0 epoch, a text PCK 
containing the constants should include the assignment 

B0DY9511010.C0NSTANTS.JED.EPOCH = ( 2433282.5D0 ) 

The same frame and epoch must be used for each planet-satellite system, but the frame and epoch 
of the constants for each system or other body may be set independently. For example, to reference 
the Earth-Moon system to the B1950 frame and J1950 epoch the assignments are 
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B0DY3_C0NSTANTS_REF_FRAME = ( 2 ) 

B0DY3_C0NSTANTS_JED.EPOCH = ( 2433282.5D0 ) 

where the nnn = 3 designates the Earth-Moon barycenter. The assignment 

B0DY399_C0NSTANTS_REF_FRAME = ( 2 ) 

B0DY399_C0NSTANTS_JED_EP0CH = ( 2433282.5D0 ) 

would be ignored by the SPICE text PCK reader routines, since a frame or epoch cannot be assigned 
to a planet or satellite. 


6.1.5 Example 

The following example is an edited snippet of the 2011 October SPICE solar system body orientation 
file pckOOOlO.tpc (|Bachman||2011|). 


KPL/PCK 

P.constants (PCK) SPICE kernel file 
Purpose 


This file makes available for use in SPICE-based applications 
software orientation and size/shape data for natural bodies. The 
principal source of the data is a published report by the lAU 
Working Group on Cartographic Coordinates and Rotational Elements. 


Mercury 

\begindata 

B0DY199_P0LE_RA = ( 281.0097 -0.0328 0. ) 

B0DY199_P0LE_DEC = ( 61.4143 -0.0049 0. ) 

B0DY199_PM = ( 329.5469 6.1385025 0. ) 

B0DY199_NUT_PREC_RA = (0. 0. 0. 0. 0. ) 

B0DY199_NUT_PREC_DEC = (0. 0. 0. 0. 0. ) 

B0DY199_NUT_PREC_PM = ( 0.00993822 

-0.00104581 
-0.00010280 
-0.00002364 
-0.00000532 ) 


\begintext 

The linear coefficients have been scaled up from degrees/day 
to degrees/century, because the SPICE PCK reader expects 
these units. The original constants were: 


\begindata 


B0DY1_NUT_PREC_ANGLES = (174.791086 0.14947253587500003E+06 

349.582171 0.29894507175000006E+06 
164.373257 0.44841760762500006E+06 
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\begintext 


339.164343 0.59789014350000012E+06 
153.955429 0.74736267937499995E+06) 


End of file pckOOOlO.tpc 


6.2 The Binary PCK Format 


Binary PCKs provide the orientation of a body-fixed reference frame, with respect to an inertial 
reference frame, sometimes called the “base frame”. This property of binary PCKs may be used 
to store the orientation of bodies whose models are too complicated to be economically stored as 
a set of coefficients. The only natural solar system bodies whose orientations are currently well 
enough known to require the use of a binary PCK file are the Earth and the Moon. The binary PCK 
format uses the DAP (Q architecture, and its structure is similar to that of the SPK. The DAP file 
identification word occupying the first eight bytes of a binary PCK is “DAF/PCK ”. 

Pike SPKs, the binary PCK summary has two double precision components {ND = 2), and five 
integer components (NI = 5). The double precision components of the summary are: 

1. the initial epoch and 

2. the final epoch 

of the interval for which data are contained in the segment, in seconds using the TDB time scale from 
J2000.0 (JD 245 1545.0). The initial and final epochs are always given using the TDB time scale 
even when the time argument used in the segment is TCB. The integer components of the summary 
are: 


1. the NAIP body-fixed frame class identification number (The reference frame for which the 
ephemeris describes its orientation.); 

2. the NAIP base frame identification number (The inertial reference frame with respect to which 
the body-fixed frame ephemeris is referenced.); 

3. the integer code for the representation (type PCK data: §6.2.2| ); 

4. the initial address of the array; and 

5. the final address of the array. 

The first two integer components of the summary are discussed in §6.2.1[ the third integer component 


is discussed in (6.2.2 and the last last two integer components are discussed in (4.1.1 


The Coordinate Time ephemeris identification numbers (1000000001, 1000000002, and 1000- 
000003) are not recognized by PCKs. 


6.2.1 Binary PCK Reference Frames 

The rotation of a body is the equivalent of the change in orientation of one reference frame, for 
example the axes of the mean lunar principal moments of inertia, with respect to a second reference 
frame, for example the ICRS, as a function of time. The first two integer components of the binary 
PCK summary are the NAIP frame class identification number of the body-fixed frame and the NAIP 
frame identification numbeiF^of the inertial base frame. The base frame must be an inertial reference 
frame. 

^^Not the frame class identification number. 
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The identification number for the ICRS is 1. Other recognized inertial reference frame names 
and their identity numbers that might be of interest are in Table 

SPICE contains a number of built-in non-inertial reference frame names and identification num¬ 
bers (Semenov 2010b I. The only non-inertial reference frames that would be of interest for binary 
PCKs are the Earth and the Moon. These reference frames are summarized in Tabled 


NAIE makes available the ITRE93 Earth orientation as a binary PCK on its web sitd^ The 


frame identification number is 13000. Bachman (20071 gives details. 

The situation for the Moon is more complicated. The Moon has two predominant reference 
frames: the axes of the principal moments of inertia (PA) reference frame and the mean Earth-mean 
pole of rotation (ME) reference frame. The PA reference frame is used for dynamical analyses 
of the Moon because its use simplifies the equations of motion. The ME reference frame is the 
historical reference frame used for locating features on the lunar surface. The difference between 
these two reference frames is a constant rotation. The ME reference frame is not stored as a binary 
PCK. It is stored as a rotation with respect to the PA reference frame in a text reference frame 
kernel^ Eurthermore, the precise orientation of the axes of the principal moments of inertia cannot 


cleanly be separated from other lunar model parameters with the available data (Williams et al. 


20131. Hence, both the PA and ME reference frames are ephemeris dependent. To deal with this 


model dependence each ephemeris solution is given a unique reference frame identification number. 
These ephemerides are then linked to the generic reference frame numbers by SPICE. Eor example 
the DE421 PA reference frame name and number are MOON_PA_DE421 and 31006, and the ME 
reference frame name and number are M00NJV1E_DE421 and 31007. The data providing the PA 
and MA reference frame identification names and numbers are part of the text reference frame kernel 
data. Eor details see|Bachman|(|2008|). 


6.2.2 Binary PCK Data Types 

The third integer component of the summary is the code for the representation, or data type. The data 
type plays no role in selecting the segment to satisfy a data request. The type used to represent the 
data becomes important only when the data in a segment are to be evaluated. This step is isolated, so 
new data types can be added to the binary PCK format without affecting application programs that 
use the higher level readers. 

SPICE currently implements two binary PCK data types that use Chebyshev polynomials. They 
are: 

• Type 2. Chebyshev polynomials (Angles): These are sets of coefficients for the angular com¬ 
ponents of the body orientation. This type is identical in structure to the Type 2 SPK; details 
of ordering of data are discussed in §6.2.3 

• Type 20. Chebyshev polynomials (Angle Rates): These are sets of coefficients for the time 
rate of change of the angular components of the body orientation. This type is identical in 
structure to the Type 20 SPK; details of ordering of data are discussed in §6.2.4 

Kernels that do not use the correct format for these data types will not be correctly interpreted by 
SPICE. Two other binary PCK data types have been defined, but are not implemented in SPICE. 
They are: 

• Type 102. Chebyshev polynomials (TCB: Angles): These are sets of coefficients for the an¬ 
gular components of the body orientation. This type is identical in structure to the Type 102 

^®ftp;//naif.jpl.nasa.gov/pub/naif/generic Jcernels/pck 

^^The format of a text reference frame kernel is similar to that of a text PCK. The main difference is that the identifi¬ 
cation word occupying the first eight bytes of a text reference kernel are “KPL/FK ”. 
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SPK; details of ordering of data are discussed in §6.2.3[ 

Type 120. Chebyshev polynomials (TCB: Angle Rates): These are sets of coefficients for 
the time rate of change of the angular components of the body orientation where the time 
argument uses the TCB time scale. This type is identical in structure to the Type 120 SPK; 


details of ordering of data are discussed in [ 6.2.4 


PCK data type identifiers 901 through 910 have been set aside for user defined data types. NAIF 
may also reserve other data types in the future. 


6.2.3 Type 2: Chebyshev Polynomials (Angles) and Type 102: Chebyshev Polynomials (TCB: 
Angles) 

PCK type 2 data type segments contain Chebyshev polynomial coefficients for the orientation of a 
body as a function of time. The structure is identical to the Type 2 SPK data type. 

Each record begins with the values for the parameters MID and RADIUS followed by the Cheby¬ 
shev polynomial coefficients for angles (j), 6, and y/, where, in SPICE, 0 is the angle in the X — Y 
plane of the inertial reference frame with its apex at the origin of the body’s reference frame from 
the positive A-axis of the inertial reference frame to the ascending node of the body’s X — Y plane, 
6 is the inclination of the body’s X — Y plane to the inertial reference frame’s X — Y plane, and y/ 
is the angle in the body’s X — Y plane from the ascending node to the body’s positive A-axis. The 
arrangement of data is shown schematically in Fig. replacing A, Y, and Z with (^,0, and yf, re¬ 
spectively. Eike the Type 2 SPK data type, the polynomial degree is fixed, so all records have the 
same number of parameters, and RSIZE is 

RSIZE = 3{PD+l) + 2 (14) 

where PD is the polynomial degree. 

PCK type 102 segments are identical to PCK type 2 data segments except that the independent 
variable uses the TCB time scale rather than the TDB time scale. 


6.2.4 Type 20: Chebyshev Polynomials (Angle Rates) and Type 120: Chebyshev Polynomials 
(TCB: Angle Rates) kernels 

PCK type 20 PCK data segments contain separate Chebyshev polynomial coefficients for the rate of 
change in orientation of the body and its orientation at t = 0 as a function of time. The structure of the 
segment is identical to that of the SPK data Type 20: Chebyshev Polynomials (velocity only). The 
only difference is that each logical record (see Fig. contains coefficients for the time derivatives 
of the angles <^, 0, and yr instead of velocities. 

Eike the Type 20 SPK data type, the polynomial degree, PD, is fixed, so the same number of 
coefficients is always used for each component, and all records are the same size: 

RSIZE = 3{PD+\) + 2. (15) 

PCK type 120 data segments are identical to PCK type 20 data segments except that the inde¬ 
pendent variable uses the TCB time scale rather than the TDB time scale. 


7 Units 

In general, the SPICE Toolkit assumes that for SPK and PCK data the unit of length is the kilometer, 
the unit of angle is the radian, and the unit of time is the second. There are some exceptions the user 
needs to be aware of: 
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PCK types 3 and 103: Angular units are degrees and angular rates are degrees second^ ^ 

SPK type 20 and 120 ( §5.3.4| ) and PCK types 20 and 120 ( §6.2.4 ): Distance and time units are 
set by the file’s creator. 


8 Validation 


Validating correct formatting is essential for complex SPK and PCK kernels. Consider writing an 
application that compares states from source data with states extracted from the kernel. Include states 
interpolated from source data not used in generating states placed in the kernel. Verify a uniform fit 
over the full time interval covered by the kernel. 

Testing with SPK or PCK kernels with a known provenance are read successfully is one method 
to assist in validation. Examples rftext PCK kernels, binary PCK type 2 and SPK type 2 kernels are 

at the IMCCE. Examples of text PCK 


available from the NAIE web site 


18 


and the INPOP web site 


19 


kernels, binary PCK type 20 and SPK type 20 kernels are available from the lAA web site 


20 


The utility applications SPY, for making structure and semantic checks of kernels, and SPKDIEE, 
for comparing similar kernels, are available at the NAIE web site These applications can assist in 
validating kernels. 

One common problem with kernels is time gaps between segments. Time gaps, even sub-second 
gaps, may cause problems for users. 

Occasionally, merging portions of two or more SPK kernels into one is required. This may be 
done by writing an appropriate application. The SPICE utility application SPKMERGE is available 
from NAII®. Carefully examine the results to verify the result is what was expected. The NAIE 
utility applications BRIEE and SPACIT are available to help with the verification. Verify that the 
comments in the merged kernel are appropriate. 


References 

Archinal, B.A., A’Heam, M.P., Bowell, E., Conrad, A., Consolmagno, G.J., Courtin, R., Eukushima, 
T., Hestroffer, D., Hilton, J.E., Krasinsky, G.A., Neumann, G., Oberst, J., Seidelmann, P.K., 
Stooke, P, Tholen, D.J., Thomas, PC., & Williams, I.P: Report of the lAU Working Group 
on Cartographic Coordinates and Rotational Elements: 2009. Celest. Mech.Dyn. Astron. 109, 
101-135 (2011a) 

Archinal, B.A., A’Heam, M.E., Bowell, E., Conrad, A., Consolmagno, G.J., Courtin, R., Eukushima, 
T., Hestroffer, D., Hilton, J.E., Krasinsky, G.A., Neumann, G., Oberst, J., Seidelmann, P.K., 
Stooke, P, Tholen, D.J., Thomas, PC., & Williams, I.P: Report of the lAU Working Group 
on Cartographic Coordinates and Rotational Elements: 2009. Celest. Mech.Dyn. Astron. 110, 
401-403 (2011b) 

Bachman, N.J.: SPICE Earth Body-fixed Reference Erame/Body Association Kernel http://naif.jpl.- 
nasa.gov/pub/naif/generic_kernels/fk/planets/earth_assocTtrf93.tf (2007). Accessed: 6 March 
2014. 

^^http://naif.jpl.nasa.gov/pub/naif/generic_k;ernels/ 

^^http;//www.imcce.fr/inpop/download 13c .php 
^*’ftp;//quasar.ipa.nw.m/incoming/EPM/Data/ 

^*http://naif.jpl.nasa.gov/naif/uti lities.html 


32 
















Hilton et al. 


Report of lAU Working Group on Access to Ephemerides 


Bachman, N.J.: SPICE Eunar Reference Erame Specification Kernel http://naif.jpl.nasa.gov- 
/pub/naif/generic_kernels/fk/satellites/moon_080317.tf (2008). Accessed: 6 March 2014. 

Bachman, N.: P_constants (PCK) SPICE kernel file. http://naif.jpl.nasa.gov/pub/naif/generic_kernelS ' 
/pck/pckOOOlO.tpc (2011). Accessed: 26 March 2015. 

Bachman, N.J.: SPK Required Reading. NAIE SPICE Toolkit Hypertext Documentation 
http://naif.jpl.nasa.gov/pub/naif/toolkit_docs/EORTRAN/req/spk.html (2014a). Accessed: 26 
March 2015. 

Bachman, N.J: SPICE Kernel Required Reading, http://naif.jpl.nasa.gov/pub/naif/toolkit docs/EOR- 
TRAN/req/kemel.html (2014b). Accessed: 26 March 2015. 

CAECEPH Eibrary http://www.imcce.fr/inpop/calceph/ (2014). Accessed: 26 March 2015. 

Ephemerides of the Planets and the Moon (EPM). ftp://quasar.ipa.nw.ru/incoming/EPM/Data/011- 
/EPM/SPICE/ (2013). Accessed: 26 March 2015. 

lAU Resolution B 1.3 Definition of Barycentric Celestial Reference System and Geocentric Celestial 
Reference System. Transactions of the lAU, XXIV B, D. Reidel Publishing Company, Dordrecht 
(2001a). 

lAU Resolution B1.9 Re-Definition of Terrestrial Time TT. Transactions of the lAU, XXIV B, D. 
Reidel Publishing Company, Dordrecht (2001b). 

lAU Resolution B3 Re-Definition of Barycentric Dynamical Time, TDB. Transactions of the lAU, 
XXVI B, Cambridge University Press, Cambridge, UK (2008). 

lAU Commission 4: Ephemerides. http://iaucom4.org/ (2015). Accessed: 19 Eebruary 2015. 

Intel: Endianess White Paper Available, at: http://www.intel.com/design/intarch/papers/endian.htm 
(2004). Accessed: 17 October 2013. 

Navigation and Ancillary Information Eacility (NAIE). http://naif.jpl.nasa.gov/naif/index.html 
(2015a). Accessed: 26 March 2015. 

Navigation and Ancillary Information Eacility (NAIF). SPICE Tutorials (Updated Eebruary 12, 
2015). http://naif.jpl.nasa.gov/naif/tutorials.html (2015b). Accessed: 26 March 2015. 

National Space Science Data Center (NSSDC). VAX Eloating Point Numbers, http://nssdc.gsfc.- 
nasa.gov/nssdc/formats/VAXPloatingPoint.htm (2014a). Accessed: 26 March 2015. 

National Space Science Data Center (NSSDC). Data Eormat and Conversion Information for Her¬ 
itage Data at the National Space Science Data Centers, http://nssdc.gsfc.nasa.gov/nssdc/formats/ 
(2014b). Accessed: 26 March 2015. 

Rivlin, T.J.: Chebyshev Polynomials, (New York: Wiley), 186 pp. (1974) 

Semenov, B.V.: Reference Erames. NAIF SPICE Toolkit Hypertext Documentation, http://naif.jpl.- 
nasa.gOv/pub/naif/toolkit_docs/EORTRAN/req/frames.html#Appendix. “Built In” Inertial Refer¬ 
ence Erames. (2010b) Accessed: 11 October 2013. 


33 



















Hilton et al. 


Report of lAU Working Group on Access to Ephemerides 


Williams, J.G., Boggs, D.H., & Folkner, W.M.: DE430 Eunar Orbit, Physical Eibrations, and Surface 
Coordinates. JPE Interoffice Memorandum lOM 335-JW,DB,WE-20130722-016 (2013) 

Wright, E.D.: DAE Required Reading. NAIF SPICE Toolkit Hypertext Documentation http://- 
naif.jpl.nasa.gOv/pub/naif/toolkit_docs/EORTRAN/req/daf.html (2013). Accessed: 26 March 
2015. 

Wright, E.D.: NAIF Integer ID codes. NAIF SPICE Toolkit Hypertext Documentation, http://- 
naif.jpl.nasa.gOv/pub/naif/toolkit_docs/FORTRAN/req/naifJds.html#NAIF Object ID numbers. 
(2014) Accessed: 26 March 2015. 

Wright, E.D. & Acton, C.: PCK Required Reading. NAIF SPICE Toolkit Hypertext Documenta¬ 
tion http://naif.jpl.nasa.gov/pub/naif/toolkit_docs/FORTRAN/req/pck.html (2013). Accessed: 26 
March 2015. 


34 








Hilton et al. 


Report of lAU Working Group on Access to Ephemerides 


A NAIF Body Identification Numbers 


Each object in the solar system is assigned a unique NAIE identification number. This appendix 
explains how these numbers are assigned, and the tables give the available identification numbers 
recognized by SPICE at the time this report was written. Current tables of identification numbers 


may be found at the NAIE web site (Wright 20141. 


A.l The Sun and Planetary Barycenters 

The smallest positive identification numbers are reserved for planetary barycenters and the Sun. 
These values are the ones most likely to be used for planetary ephemerides. The NAIE identification 
numbers for these objects are given in Table Eor those planets without satellites, Mercury and 
Venus, the barycenter location is identical to the location of the body center of mass. However, a 
planet barycenter identification number may not be interchanged with a planet identification number 
described in §A.2 A barycenter has only the attributes of mass and position, while a planet has 
additional attributes such as size, shape and rotation pole and rate of rotation. The position ephemeris 
of a planet-satellite system is designated by its barycenter identification number, but the physical 
ephemeris of the planet itself is designated by its planet identification number. 


Table 4: NAIE identification numbers for the Sun and planetary barycenters. 


NAIE ID 

Name 

0 

Solar System Barycenter 

1 

Mercury Barycenter 

2 

Venus Barycenter 

3 

Earth-Moon Barycenter 

4 

Mars Barycenter 

5 

Jupiter Barycenter 

6 

Saturn Barycenter 

7 

Uranus Barycenter 

8 

Neptune Barycenter 

9 

Pluto“ Barycenter 

10 

Sun 


“Pluto is included here due to its pre¬ 
vious classification as a planet. 
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A.2 Planets and Satellites 

The format of planet identification numbers is: 

P99 

where P is the number of the planet in increasing distance from the Sun, e.g. Jupiter is body number 
599. Pluto is included in this scheme as a continuation of its previous status as a planet. 

Similarly, the format for satellites identification numbers is either 

PNN or PXNNN 


where A is a digit and X is 0 or 5. The digits NN or NNN are unique for a given value of P. 
These digits are the same as the lAU Roman numerals for a satellite. For example, Ananke, the 12th 
satellite of Jupiter (JXII), is body number 512. Codes with X = 5 are provisional. 

The current planet and satellite identification numbers recognized by SPICE (Wright 20141 are 
given in Table 


Table 5: NAIF identification numbers for planets and satel¬ 
lites. 


NAIF ID 

Name 

lAU Desig. 

NAIF ID 

Name 

lAU Desig. 

199 

Mercury 


516 

Metis 

JXVI 




517 

Callirrhoe 

JXVII 

299 

Venus 


518 

Themisto 

JXVIII 




519 

Magaclite 

JXIX 

399 

Earth 

El 

520 

Taygete 

JXX 

301 

Moon 


521 

Chaldene 

JXXI 




522 

Harpalyke 

JXXII 

499 

Mars 


523 

Kalyke 

JXXIII 

401 

Phobos 

MI 

524 

locaste 

JXXIV 

402 

Deimos 

Mil 

525 

Erinome 

JXXV 




526 

Isonoe 

JXXVI 

599 

Jupiter 


527 

Praxidike 

JXXVII 

501 

lo 

JI 

528 

Autonoe 

JXXVIII 

502 

Europa 

JII 

529 

Thyone 

JXXIX 

503 

Ganymede 

Jill 

530 

Hermippe 

JXXX 

504 

Callisto 

JIV 

531 

Aitne 

JXXXI 

505 

Amalthea 

JV 

532 

Eurydome 

JXXXII 

506 

Himalia 

JVI 

533 

Euanthe 

JXXXIII 

507 

Elara 

JVII 

534 

Euporie 

JXXXIV 

508 

Pasiphae 

JVIII 

535 

Orthosie 

JXXXV 

509 

Sinope 

JIX 

536 

Sponde 

JXXXVI 

510 

Eysithea 

JX 

537 

Kale 

JXXXVII 

511 

Carme 

JXI 

538 

Pasithee 

JXXXVIII 

512 

Ananke 

JXII 

539 

Hegemone 

JXXXIX 

513 

Eeda 

JXIII 

540 

Mneme 

JXE 

514 

Thebe 

JXIV 

541 

Aoede 

JXEI 

515 

Adrastea 

JXV 

542 

Thelxinoe 

JXEII 
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Table 5: (Continued) 


NAIF ID 

Name 

lAU Desig. 

NAIF ID 

Name 

lAU Desig. 

543 

Arche 

JXEIII 

635 

Daphnis 

sxxxv 

544 

Kallichore 

JXEIV 

636 

Aegir 

SXXXVI 

545 

Helike 

JXEV 

637 

Bebhionn 

SXXXVII 

546 

Carpo 

JXEVI 

638 

Bergelmrr 

SXXXVIII 

547 

Eukelade 

JXEVII 

639 

Bestla 

SXXXIX 

548 

Cyllene 

JXEVIII 

640 

Farbauti 

SXE 

549 

Kore 

JXEIX 

641 

Fenrir 

SXEI 

550 

Herse 

JE 

642 

Fomjot 

SXEII 




643 

Hati 

SXEIII 

699 

Saturn 


644 

Hyrokkin 

SXEIV 

601 

Mimas 

SI 

645 

Kari 

SXEV 

602 

Enceladus 

SII 

646 

Eoge 

SXEVI 

603 

Tethys 

Sill 

647 

Skoll 

SXEVII 

604 

Dione 

SIV 

648 

Surtur 

SXEVIII 

605 

Rhea 

SV 

649 

Anthe 

SXEIX 

606 

Titan 

SVI 

650 

Jarnsaxa 

SE 

607 

Hyperion 

SVII 

651 

Greip 

SEI 

608 

lapetus 

SVIII 

652 

Tarqeq 

SEII 

609 

Phoebe 

SIX 

653 

Aegaeon 

SEIII 

610 

Janus 

SX 




6II 

Epimetheus 

SXI 

799 

Uranus 


612 

Helene 

SXII 

701 

Ariel 

UI 

613 

Telesto 

SXIII 

702 

Umbriel 

UII 

614 

Calypso 

SXIV 

703 

Titania 

UIII 

615 

Atlas 

sxv 

704 

Oberon 

UIV 

616 

Prometheus 

SXVI 

705 

Miranda 

UV 

617 

Pandora 

SXVII 

706 

Cordelia 

UVI 

618 

Pan 

SXVIII 

707 

Ophelia 

UVII 

619 

Ymir 

SXIX 

708 

Bianca 

UVIII 

620 

Paaliaq 

sxx 

709 

Cressida 

UIX 

621 

Tarvos 

SXXI 

710 

Desdemona 

UX 

622 

Ijiraq 

SXXII 

711 

Juliet 

UXI 

623 

Suttungr 

SXXIII 

712 

Portia 

UXII 

624 

Kiviuq 

SXXIV 

713 

Rosalind 

UXIII 

625 

Mundilfari 

sxxv 

714 

Belinda 

UXIV 

626 

Albiorix 

SXXVI 

715 

Puck 

uxv 

627 

Skathi 

SXXVII 

716 

Caliban 

UXVI 

628 

Erriapus 

SXXVIII 

717 

Sycorax 

UXVII 

629 

Siarnaq 

SXXIX 

718 

Prospero 

UXVIII 

630 

Thrymr 

sxxx 

719 

Setebos 

UXIX 

631 

Narvi 

SXXXI 

720 

Stephano 

uxx 

632 

Methone 

SXXXII 

721 

Trinculo 

UXXI 

633 

Pallene 

SXXXIII 

722 

Francisco 

UXXII 

634 

Polydeuces 

SXXXIV 

723 

Margaret 

UXXIII 
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Table 5: (Continued) 


NAIF ID 

Name 

lAU Desig. 

NAIF ID 

Name 

lAU Desig. 

724 

Ferdinand 

UXXIV 

807 

Farissa 

NVII 

725 

Perdita 

UXXV 

808 

Proteus 

NVIII 

726 

Mab 

UXXVI 

809 

Halimede 

NIX 

727 

Cupid 

UXXVII 

810 

Psamathe 

NX 




8II 

Sao 

NXI 

899 

Neptune 


812 

Faomedeia 

NXII 

801 

Triton 

NI 

813 

Neso 

NXIII 

802 

Nereid 

Nil 




803 

Naiad 

NIII 

999 

Pluto“ 


804 

Thalassa 

NIV 

901 

Charon 

PI 

805 

Despina 

NV 

902 

Nix 

PII 

806 

Galatea 

NVI 

903 

Hydra 

PHI 


“Pluto is included here because of its previous classification as a planet. 
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A.3 Comets 


Identification numbers for periodic comets begin at 1,000,001 and continue in sequence up to 2,000,- 
000. The current list of periodic comets ( Wrightj 20141 and their identification numbers are given 
in Table The identification number for a new comet is formed by adding one to the last comet 
identification number in the current SPICE list. The first part of the list through identification number 
1,000,112 is in alphabetical order. Comet Shoemaker Eevy 9 is included in this list, identification 
number 1,000,130, though it is no longer a comet, periodic or otherwise. 


Table 6: NAIF identification numbers for comets. 


NAIE ID 

Name 

NAIE ID 

Name 

1000001 

Arend 

1000037 

Haneda-Campos 

1000002 

Arend-Rigaux 

1000038 

Harrington 

1000003 

Ashbrook-J ackson 

1000039 

Harrington-Abell 

1000004 

Boethin 

1000040 

Hartley 1 

1000005 

Borrelly 

1000041 

Hartley 2 

1000006 

Bowell-Skiff 

1000042 

Hartley-IRAS 

1000007 

Bradfield 

1000043 

Herschel-Rigollet 

1000008 

Brooks 2 

1000044 

Holmes 

1000009 

Brorsen-Metcalf 

1000045 

Honda-Mrkos-Pajdusakova 

1000010 

Bus 

1000046 

Howell 

1000011 

Chernykh 

1000047 

IRAS 

1000012 

Churyumov-Gerasimenko 

1000048 

Jackson-Neujmin 

1000013 

Ciffreo 

1000049 

Johnson 

1000014 

Clark 

1000050 

Kearns-Kwee 

1000015 

Comas Sola 

1000051 

Klemola 

1000016 

Crommelin 

1000052 

Kohoutek 

1000017 

d’Arrest 

1000053 

Kojima 

1000018 

Daniel 

1000054 

Kopff 

1000019 

de Vico-Swift-NEAT 

1000055 

Kowal 1 

1000020 

Denning-Eujikawa 

1000056 

Kowal 2 

1000021 

du Toit 1 

1000057 

Kowal-Mrkos 

1000022 

du Toit-Hartley 

1000058 

Kowal-Vavrova 

1000023 

du Toit-Neujmin-Delporte 

1000059 

Eongmore 

1000024 

Dubiago 

1000060 

Eovas 1 

1000025 

Encke 

1000061 

Machholz 

1000026 

Eaye 

1000062 

Maury 

1000027 

Einlay 

1000063 

Neujmin 1 

1000028 

Eorbes 

1000064 

Neujmin 2 

1000029 

Gehrels 1 

1000065 

Neujmin 3 

1000030 

Gehrels 2 

1000066 

Gibers 

1000031 

Gehrels 3 

1000067 

Peters-Hartley 

1000032 

Giacobini-Zinner 

1000068 

Pons-Brooks 

1000033 

Giclas 

1000069 

Pons-Winnecke 

1000034 

Grigg-Skjellerup 

1000070 

Reinmuth 1 

1000035 

Gunn 

1000071 

Reinmuth 2 

1000036 

Halley 

1000072 

Russell 1 
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Table 6: (Continued). 


NAIF ID 

Name 

NAIF ID 

Name 

1000073 

Russell 2 

1000103 

van Houten-Femmon 

1000074 

Russell 3 

1000104 

West-Kohoutek-Ikemura 

1000075 

Russell 4 

1000105 

Whipple 

1000076 

Sanguin 

1000106 

Wild 1 

1000077 

Schaumasse 

1000107 

Wild 2 

1000078 

Schuster 

1000108 

Wild 3 

1000079 

Schwassmann-Wachmann 1 

1000109 

Wirtanen 

1000080 

Schwassmann-Wachmann 2 

1000110 

Wolf 

1000081 

Schwassmann-Wachmann 3 

1000111 

Wolf-Harrington 

1000082 

Shajn-Schaldach 

1000112 

Fovas 2 

1000083 

Shoemaker 1 

1000113 

Urata-Niijima 

1000084 

Shoemaker 2 

1000114 

Wiseman-Skiff 

1000085 

Shoemaker 3 

1000115 

Helin 

1000086 

Singer Brewster 

1000116 

Mueller 

1000087 

S laughter-B urnham 

1000117 

Shoemaker-Holt 1 

1000088 

Smimova-Chernykh 

1000118 

Helin-Roman-Crockett 

1000089 

Stephan-Oterma 

1000119 

Hartley 3 

1000090 

Swift-Gehrels 

1000120 

Parker-Hartley 

1000091 

Takamizawa 

1000121 

Helin-Roman-Alu 1 

1000092 

Taylor 

1000122 

Wild 4 

1000093 

Tempel 1 

1000123 

Mueller 2 

1000094 

Tempel 2 

1000124 

Mueller 3 

1000095 

Tempel-Tuttle 

1000125 

Shoemaker-Fevy 1 

1000096 

Tritton 

1000126 

Shoemaker-Fevy 2 

1000097 

Tsuchinshan 1 

1000127 

Holt-Olmstead 

1000098 

Tsuchinshan 2 

1000128 

Metcalf-Brewington 

1000099 

Tuttle 

1000129 

Fevy 

1000100 

T uttle- Giacobini- Kres ak 

1000130 

Shoemaker-Fevy 9 

1000101 

Vaisala 1 

1000131 

Hyakutake 

1000102 

Van Biesbroeck 

1000132 

Hale-Bopp 


A.4 Asteroids and Dwarf Planets 

The format for identification numbers of numbered asteroids and dwarf planets, aside from Pluto, is: 
identification number = 2,000,000 + lAU asteroid number 


For example, asteroid (2956) Yeomans has identification number 2,002,956. 

Due to its previous classification as a planet, Pluto and its satellites are included with the plane¬ 
tary barycenters ( §A.l ) and with planetary centers and their satellites ((A.2). 

There are three other exceptions to the asteroid identification assignment rule 

• (951) Gaspra: identification number 9511010 

• (243) Ida: identification number 2431010, and 

• (243) 1 Dactyl, Ida’s satellite, identification number 2431011. 
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The identification numbers for these asteroids were assigned using an older numbering convention 
now abandoned by the SPICE system. A conflict will arise between the new numbering system and 
the identification number for Ida if more than 431,010 asteroids are ever identified and cataloged. At 
that time NAIE will add another exception to the asteroid numbering system. 
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